A generated TypeScript client now ships in-repo at clients/typescript, derived from openapi.yaml and enforced in CI. Types are never hand-written: schema.d.ts is produced by openapi-typescript, and openapi-fetch provides a typed createLensClient. CI regenerates the client on every run and fails if the committed output diverges from the spec, then typechecks it. This session repaired the two files that had been corrupted, added the documented usage example and README section - #403

… client

Merging #403 turned main red. The client generator it wires into CI could not
run at all:

  Error: Can't resolve $ref at #/paths/~1price~1{asset}~1fiat/get/responses/400

`openapi.yaml` referenced `#/components/responses/BadRequest` from
`/price/{asset}/fiat`, and `components.responses` defines only
`PaymentRequired` and `TooManyRequests`. The reference has presumably been
dangling for a while; nothing read the spec strictly enough to notice until
#403 added a generator that does. Replaced it with the inline
`description: Invalid parameters` that every other 400 in this file uses, and
swept the rest: every `$ref` into components/schemas, components/parameters
and components/responses now resolves.

The committed `clients/typescript/src/schema.d.ts` was also stale by
+2,665/-255 lines — it predated `/venues/registry` among others — so #403's
own `git diff --exit-code -- clients/typescript` guard would have failed next
even after the $ref was fixed. Regenerated it, and regenerated openapi.json
from the YAML.

My fault for not catching this before merging: I ran `npm run client:gen` with
its output suppressed and read the absence of a diff as success, when in fact
`openapi-typescript` is not installed in this checkout and the script never
ran. Verified properly this time with `npx openapi-typescript@7.13.0`.

Verified: tsc clean, 113 files / 1,401 tests passing, every $ref resolves, and
the client regenerates byte-identically from the committed spec.

Still not verified locally: `npm run client:typecheck`. openapi-fetch is in
the lockfile but absent from this node_modules, and npm cannot add it here
("Cannot read properties of null (reading 'edgesOut')") without a full
reinstall I will not risk on Windows — this lockfile lost its @rolldown Linux
binding to a Windows regeneration earlier today. CI runs that step.

Claude-Session: https://claude.ai/code/session_01USgemLt4Rnz4SGB1Srf3GB

`client:typecheck` failed on the example that #403 ships:

  example.ts(47,34): error TS2339: Property 'count' does not exist on type
  'Readable<SuccessResponse<{ 200: { content: { "text/csv": string;
  "application/json": { ... count?: number ... } } } }>>'

/prices/history answers text/csv as well as application/json, so the generated
types give a union and a field read has to narrow first. The example only
compiled before because the committed schema.d.ts was stale by 2,665 lines and
predated the CSV variant.

Narrowed with a typeof check and said why in a comment: the compiler insisting
on it is the point of generating the client from the spec instead of
hand-writing one.

Claude-Session: https://claude.ai/code/session_01USgemLt4Rnz4SGB1Srf3GB

#584 documented the half-open [from, to) semantics on the `from` and `to`
query parameters in openapi.yaml, and the generated client carries those
descriptions as JSDoc. I merged it without regenerating, so #403's
`git diff --exit-code -- clients/typescript` guard failed on main — which is
the guard doing exactly its job one merge after it was added.

Claude-Session: https://claude.ai/code/session_01USgemLt4Rnz4SGB1Srf3GB

The endpoint reported a liquidity number with no stated unit, source or
formula, which makes it uninterpretable: a consumer cannot tell whether two
rows are comparable, let alone what currency the figure is in.

Now documented at the top of the route — AMM pools for the pair, summed
`(reserve_a * spot_price + reserve_b)`, denominated in the quote asset — and,
more usefully, each row carries `liquidity_unit` so the answer travels with
the data instead of living in a doc comment. The response also names the
network it was computed for.

The formula comment is right, which is worth noting because this is the kind
of thing that gets written down wrong: spot_price is asset_b per asset_a, so
`reserve_a * spot_price` is reserve_a valued in asset_b, and for a
constant-product pool that equals reserve_b — the sum is the whole pool's
value in quote terms rather than a double count.

Earlier type errors are gone. Regenerated the TypeScript client, since
openapi.yaml changed and #403's drift guard checks it.

Lens: 115 files, 1,423 tests passing, typecheck clean.

Claude-Session: https://claude.ai/code/session_01USgemLt4Rnz4SGB1Srf3GB

computeTWAP already took a `network` and filtered on it (`AND network = $2`),
but the routes never passed one, so the figures were computed for whatever the
default was rather than the network the caller asked for. Same class of bug as
#584 found in /candles, /basket and /benchmark — a price that silently mixes
or mistakes chains.

Both routes now resolve `req.network ?? query.network ?? activeNetwork`,
thread it into the computation and echo it in the response, so a caller can
see which chain answered. 122 lines of new route tests cover it.

Conflicts, all additive against work that landed today: #542 added the
decimal-format handling in the same schema and handler blocks this PR adds
`network` to. Unioned — the query schema now carries decimals, decimalFormat
and network, and the handler does both.

Two things I regenerated rather than merged by hand: openapi.json, because it
is generated from openapi.yaml and a hand-merged copy fails the
generator-match test, and the TypeScript client, because #403's drift guard
checks it. Took main's package-lock.json; this PR changes no dependency and
main's is the copy carrying the @rolldown Linux binding CI needs.

Lens: 116 files, 1,426 tests passing, typecheck clean.

Claude-Session: https://claude.ai/code/session_01USgemLt4Rnz4SGB1Srf3GB